Distributed data processing and computer networks are nowadays pervasive.
A successful paradigm in distributed data processing is the client-server architecture. A client-server software product generally comprises a client application component, intended to be installed on, and executed by one or more endpoints, i.e. target data processing apparatuses (e.g., Personal Computers—PCs—, workstations, and the like) of a computer network, and a server application component, intended to be installed on and executed by a server data processing apparatus of the network, in data communications relationship with then endpoints.
Some known distributed software products have a client component that comprises a software agent, intended to be installed on and to be executed by several endpoints, and a server component, installed on a network server. The software agents running on the different endpoints are adapted to gather information from one or more information sources available at the respective endpoints, and to upload the gathered information to the server component. The server component manages an information repository, which is a database on which the information gathered and uploaded by the different software agents running on the different endpoints is stored. The server component also includes a specifically-designed user interface through which a user can access the information stored in the repository.
It happens more and more frequently that it is necessary, or at least desirable to integrate two or more already existing, distinct software products into a combined solution, adapted to put together the functionalities offered by each single product, so as to make a more complete and powerful suite available to the customers.
The integration of the two or more existing products into a suite should involve the minimum possible modifications to the products themselves, so as to minimize costs and time to market of the integrated suite.
When integrating two or more existing software products, the necessity may arise of guaranteeing that the data generated by one software application are kept synchronized, and stored in a respective repository at the same time as the data generated by the other software application(s) of the suite. This is for example the case when it is desired to integrate two or more software products of the type described above, each of which is adapted to gather data from an information source available at the endpoint where the software agent is installed, and to upload the data gathered to the server component, for their storage in the proper central repository.
Assuming for example the case that two such products need to be integrated, the scenario to be considered is that of two different software agents that are installed on and executed by an endpoint, and that gather data on the endpoint, either from a same or from different information sources; the data gathered by the two software agents are then independently uploaded to the respective server component, that stores the collected data into the respective repository. Being the two software products distinct, the two software agents installed on and executed by the generic endpoint are each unaware of the existence of the other; they in general start the data collection mechanism in different ways and at different times; in other words, they behave in a totally uncorrelated way. When a user accesses the two repositories, exploiting the respective user interfaces, he/she may note that the information gathered by the two software agents and stored in the two repositories, albeit relating to the same endpoint, tend to differ with the passage of time, because the data are collected at the endpoint at different times.
In the pursuit of the achievement of an integration of the two products, this is regarded as undesirable. This kind of data inconsistency should be avoided, and the data maintained by the two or more software products in the respective repositories should be kept synchronized.
One possible way to synchronize the data is at the server component level; this usually calls for exploiting a database synchronization mechanism, also referred to as “data replication”. Each of the two or more software applications to be integrated is responsible of uploading and storing its own data into the respective repository, in the usual way, i.e. in a way totally unaware of the presence of the other application(s). A tool external to the software applications to be integrated together is provided, that is in charge of moving the updated information from one database to the other(s).
Another possible way to keep data synchronized between two or more software applications is at the client component level: in this case, the synchronization of the data is accomplished at the level of the client component, instead of at the level of the server component of the software products. Referring to the above example, let it be assumed that when the software agent of one of the two software products to be integrated collects data also collected by the software agent of the other software product, the upload of the data is also triggered in respect of the data gathered by the other software agent. In other words, every time a software agent, running on a generic endpoint, has to collect data and upload them to the server, so that they are stored in the respective repository, it notifies the other software agent(s) running on that endpoint about its activity, so that also the other software agent(s) can start the data gathering and upload. In this way, over time the information that is stored in the different central repositories and that can be accessed by a user through the user interfaces of the two software products is the same.